Subject: Option Set 1301

From: "J. G. Dudley (444/4358)" <[email-masked]>
Date: Mon, 31 Jul 95 13:39:03 EDT

Dario,

>1. I quote APPN Option Set 1301 from the APPN Reference (SC30-3422-03):
>
>The ability of session connectors in an
>APPN network node to receive nonpaced
>session traffic.  When a node implements
>options set 1301, SCM can accept nonnegoti-
>tiable BINDs and RSP(BIND)s request the
>node to receive nonpaced session traffic.
>Otherwise, the session is deactivated.
>
>Does the nonnegotiable apply to BINDs and RSP(BIND)s or can the
>RSP(BIND)s be either negotiable or nonnegotiable RSP(BIND)s?

Nonnegotiable applies to both BIND and RSP(BIND), but this is a very
tricky area.  When SCM receives a RSP(BIND) (negotiable or nonnegotiable)
with the ASPI set to 0, it uses the primary receive window size it sent
in BIND as its fixed received window size for the secondary stage.  When
SCM forwards a negotiable BIND, it does not set any of the pacing window
sizes to 0.

When SCM forwards a nonnegotiable BIND, it does not change the pacing
window sizes received in BIND; as a result, it may forward the BIND
with the primary receive window size set to 0.  This is the only case
in which the receive pacing type on the secondary stage can be none.
When the receive pacing type on the secondary stage is none, an SCM
not supporting option set 1301 deactivates the session.

>2. What is the pacing type on a secondary stage with the following
>negotiable LU6.2 bind exchange?
>
>NN1---------NN2--------
>
>                    <----------BIND Rq (bytes 8-13 = don't care)
>
><------------BIND Rq (bytes 8-13 = 00 80 85 85 80 00)
>
>------------>BIND Rsp (bytes 8-13 = 00 01 85 85 81 00)

This is not a valid scenario for a negotiable BIND exchange.  As
mentioned above, SCM does not set any of the pacing window sizes to
0 in a forwarded negotiable BIND.  If the BIND were nonnegotiable,
fixed pacing with a window size of 1 would be used from NN2 to NN1.
Provided that NN2 supported option set 1301, no pacing would be done
from NN1 to NN2.

>Is it okay for the ISR node NN2 to send a BIND Rq w/ ASPI on and
>specify 0 for the primary/secondary send/receive window sizes?

No.

>It seems like the primary receive window size should not be 0 on the
>BIND Rq when ASPI is on.  Is this true?

The primary receive window size should not be 0 with the ASPI either
on or off.

>Based on page 11-13 of the above book it would appear the 0 is not a
>suitable value for either fixed or adaptive pacing.  I was trying
>to decode the first paragraph.

That is correct.

Regards,
Gary Dudley
IBM APPN Architecture Team